Work item tracking systems are often used in today's business world, particularly in software development environments. Work item tracking systems typically enable users to define one or more work items representing units of work, and track the progress of the units of work by updating the work items representing the units of work. A unit of work can be of any of a variety of types, including, but not limited to: a task to be performed by one or more persons; software related work items such as a bug fix (i.e., correction of a software defect) or an improvement/addition to a software application; a project; another type of work item, or any combination of the foregoing. As used herein, a “work item” is a software abstraction (e.g., object, class, record, array, other type of abstraction, or suitable combination of the foregoing) representing and defining a unit of work. A “work item tracking system” or “WITS” is a system that enables the tracking of units of work by enabling manual (by users) and possibly automatic (by the system in response to other events on the system) creation and modification of work items.
Some work item tracking systems are hard-coded to provide different access privileges to different users and/or enable different users to perform different actions on work items. For example, a first software developer (e.g., from a first development team) may be allowed to access and modify a first work item, a second software developer (e.g., from a second development team) may be allowed to access, but not modify (e.g., read-only) the first work item, and a third software developer (e.g., from a third development team) may be denied access to the first work item altogether. These access and modification “rules” are not separately-identifiable, discrete software entities, but rather, their definition and functionality are embedded within the code that controls access to and manipulation of work items (i.e., they are hard-coded). Thus, they are not readily available for use (i.e., re-usable) and subject to alternative interpretation by other entities (i.e., programs and applications).
Further, these rules are closed (not exposed) to users such that they are not subject to creation or change by users. The code must be altered by programmers. Over time, a business's employees, corporate structure, business goals, products and other aspects of the business change. In response to such change, it may be desirable to change the access and modification rules for work items (e.g., add, delete and/or modify one or more rules). However, as described above, this change must be made by a programmer. Thus, an administrator (or other person that desires the change) cannot make the change herself/himself, but must explain the needed modification to a programmer. Further, the administrator can't readily see (except in code form) the actual changes made by the programmer to the code, but can only experience the results of such changes. If the changes do not produce the desired result, the administrator must go back to the programmer and explain the problem, and the process is repeated. This process, requiring interaction between an administrator and programmer for implementing changes to access and/or modification rules, is an inefficient use of business resources.